In the course of creating computer programs, it is frequently useful to know the hardware implications of using a particular programming language construct. For example, if calling a particular procedure commits some physical resource of the underlying machine, that resource may not be available for use by other procedures. Programmers need to know this information in order to write correct and efficient code. In many programming systems, the programmer must rely on memory and written notes to manage this information. As systems become more and more complex, this task becomes more and more difficult.
An important instance of this problem occurs in assembly language coding for processors containing multiple functional units. An example of such a processor is the Texas Instruments TMS320C80 DSP PP processor, in which a single instruction may specify four or more separate operations. The TMS320C8x PP is an advanced fixed-point DSP processor with multiple functional units. It has a 64-bit instruction word that can encode up to four parallel operations, e.g. an ALU operations, a multiply, and two memory accesses with index modifications. It also has a three-input ALU, which gives it an unusually rich repertoire of data unit operations. This power places a significant burden on the programmer. In addition to remembering what each functional unit can do, he or she must master a complex set of rules governing which operations can be performed in parallel. This is an daunting task, and beginning programmers find writing, parallel instructions difficult and frustrating. Because of hardware constraints, not all combinations of operations constitute legal instructions. Memorizing the constraints is difficult and painful, so programmers (particularly novice or occasional programmers) have great difficulty producing correct assembly language source files.
A few tools for parallel programming include methods of providing feedback to the programmer about the performance impact of code constructs. The ParaScope editor (K. Kennedy, et al., "Interactive Parallel Programming Using the ParaScope Edition," IEEE Trans. on Parallel and Distributed Systems, V.2, No. 3 pp. 329-341, July 1991.) from Rice University is the example that is closest to our invention. ParaScope consists of a source code browser connected to a compiler for a parallel dialect of Fortran. On command from the user, it compiles the program and identifies aspects of the code that affect its suitability for parallel execution, such as loop-carried data dependencies. It displays these using color coding and arrows drawn between lines of source code. ParaScope can only be used after the entire program is written. This requirement follows from the fact that it displays information that can only be determined by compiling the entire program. In addition, ParaScope does not provide any way to display resource utilization.
For the specific problem of assembly language coding, resource conflicts are typically documented in the processor language manual. See the TMS320C80 PP programmer's manual for an example.(TMS320C8x(MVP) Online Reference release (CD ROM) of Texas Instruments Incorporated, Dallas, Tex. 1995) The problem with this is that the rules are complex and difficult for the programmer to remember while coding. As a result, programmers often produce code that violates the rules, i.e. contains resource conflicts. These conflicts are eventually detected when the programmer runs the assembler to translate the source code into object code. At that point the programmer must find the corresponding lines of source code and try to determine what is wrong by reading the manual and error messages. However, the long delay between generating an erroneous instruction and detecting it makes program development tedious and frustrating.
Error messages from language translators (compilers and assemblers) are the standard method of describing resource conflicts in the source code. They invariably appear as text messages and are informative to varying degrees.
Integrated programming environments (e.g., Visual C++, Microsoft Visual C++ 4.1, software Microsoft, Inc. Redmond, 1995) have features that address some of the problems described here. These systems typically integrate the source code editor with the language translator. The translator can be invoked from within the editor; when an error is detected, the editor cursor can jump to the line containing the error. This reduces the delay between error generation and correction. However, no efforts can be detected until the user attempts to translate the entire source file. Also, integrated programming systems do not address resource conflicts.
The programming tool that is (to our knowledge) most similar to our invention, to follow is the program editor for the Aspex PIPE (Kent, et al., "PIPE, Piplined Image Processing Engine," Journal of Parallel and Distributed Computing 2, 1985, pp. 50-78.) image processor. The PIPE was controlled by 256-bit microcode words specifying multiple operations, so it was subject to the programming problem addressed by the present invention. ASPEX provided a programming tool allowing the programmer to create assembly language instructions by interacting with a block diagram of the processor. For example, to express the addition of two data items, the programmer would use a mouse to make multiplexor connections that routed the data from its registers to the ALU and from the ALU back to registers. The ALU operation would then be set by selecting "add" from a menu. These mouse operations would translate directly into values for the fields of the microcode word. The advantage of this system was that it was impossible to create resource conflicts: every resource was visible, and assigning it to one task necessarily took it away from another task.
The ASPEX PIPE tool has the following disadvantages. First, it only applies to processors that are simple enough to lay out and manipulate on a workstation screen. Second, it provides no obvious way to express conflicts that are due to limited instruction bandwidth. In the case of the TMS320C80, for example, some conflicts occur not because there are not enough functional units to do a pair of operations, but rather because the instruction word does not contain enough bits to encode both operations simultaneously. Finally, the ASPEX system requires the programmer to be more specific than necessary. For example, if there are multiple ways to perform a given operation, the ASPEX system requires the programmer to choose one. The wrong choice may interfere with other operations that could be performed in parallel.